Danny Amor's Online Library/Danny Amor's Online Library - Volume 1.iso/html/faqs/alt/windows.cde

Internet Message Format | 1994-10-18 | 66KB

Path: bloom-beacon.mit.edu!hookup!swrinde!cs.utexas.edu!convex!news.duke.edu!eff!blanket.mitre.org!linus.mitre.org!newsflash.mitre.org!mitre.org!cap
From: [e-mail] (Craig Prall)
Newsgroups: alt.windows.cde,alt.answers,comp.answers,news.answers
Subject: Common Desktop Environment (CDE) Frequently Asked Questions
Followup-To: alt.windows.cde
Date: 13 Oct 1994 15:35:07 GMT
Organization: The MITRE Corporation
Lines: 1314
Approved: [e-mail]
Distribution: world
Expires: 11 Nov 1994 23:00:00 GMT
Message-ID: <37jk3b$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: future.mitre.org
Summary: Answers to common questions about CDE and the Common Open
    Software Environment (COSE) as discussed in alt.windows.cde
    newsgroup. Read this before posting your question to ....
Keywords: CDE, COSE, desktop, user environment
Xref: bloom-beacon.mit.edu alt.windows.cde:106 alt.answers:4986 comp.answers:7777 news.answers:27361

Archive-name: cde-cose-faq
Last-modified: 1994/10/07
Version: 1.2
Posting-Frequency: monthly


1.0    WHERE AM I?

1.1    What is alt.windows.cde?

This newsgroup is dedicated to the exchange of news and information
about the Common Desktop Environment (CDE) being created as a part of
the Common Open Software Environment (COSE) for UNIX-based
workstations.  It is *not* for Microsoft Windows questions.  Those
belong in comp.os.ms-windows.apps or some such newsgroup.

1.2    What is this posting?

This is the alt.windows.cde FAQ list for October 7, 1994.

When the alt.windows.cde newsgroup was formed, I thought that there
would be constant updates posted here by the COSE vendors.  This
hasn't happened.  This is somewhat understandable; they are extremely
busy right now.  Also, it was pointed out to me by one of the CDE
developers that with four companies involved, it is hard to remember
what is and is not public knowledge, so it is better to not say
anything lest one company give away another's trade secret.  What this
is then is the author's, coworker's, and contributor's current
understanding of the CDE and COSE in general.  Although this newsgroup
is about the CDE specifically, there is no COSE newsgroup (yet), so
this is a logical place to describe the other COSE technology areas,
too.  Much of the text in this FAQ is (currently) based on a paper and
briefing done in November of 1993 so if it has the feel of a tutorial
rather than a traditional FAQ, that is why.

If you have questions (and even better - answers/additions) you would
like to see added to this list, send e-mail to: [e-mail]

1.3    Legal Stuff

This FAQ list should not be construed as an official "policy"
statement of my employer, the MITRE corporation.  Also, all statements
herein should not be regarded as undeniable facts.  (i.e., You can't
sue me or MITRE if they are wrong.) For one thing, several of these
"facts" have changed dramatically since the (bulk of) text below was
orginally written in November, 1993.  Although I have updated them to
the best of my knowledge at this time, I can almost guarantee some of
them will change again.  Since it isn't my full time job to update
this list, it won't be current at all times.

Also, there are a lot of trademarked names in this FAQ list.  Those
trademarks belong to their respective trademark holders.

1.4    What's in the FAQ?

The sections and questions below are:

  2.0     COSE OVERVIEW
  2.1    In general terms, what is COSE and why do we need it?
* 2.2    How does COSE work / What is the "new" OSF?
* 2.3    How does COSE fit into the existing standards processes?

  3.0    DETAILS ABOUT COSE
  3.1    What all does the COSE process encompass?
* 3.2    What are the Common UNIX APIs?
  3.3    What is going on in graphics?
  3.4     What is COSE doing about multimedia?
  3.5     What is COSE doing in regards to objects?
  3.6     What is COSE doing in the area of distributed computing?
  3.7     What is COSE doing about system management?
  3.8     What is the Public Windows Interface (PWI)/WABI?
  3.9     What is COSE doing about Federated Naming?
  3.10     What is COSE doing about Data Management?
  3.11    How will the COSE technologies be packaged?

* 4.0    DETAILS ABOUT THE COMMON DESKTOP ENVIRONMENT (CDE)
  4.1    What is in the CDE?
  4.1.1    What is the CDE desktop?
  4.1.2    What is the Front Panel?
  4.1.3    What is the File Manager?
  4.1.4    What is the Application Manager?
  4.1.5    What is Application and File Action Binding/Typing?
  4.1.6    What is Session Management?
  4.1.7    How do I program with the CDE?
  4.1.8    How does CDE do drag-and-drop?
  4.1.9    How does CDE support remote application execution?
  4.1.10 How does CDE support inter-application communication?
  4.1.11 What utilities are included?
  4.1.12 What applications are included?
  4.1.13 What is the CDE Print Server?
  4.1.14 What is the Help System?
  4.1.15 Any other features?
* 4.2    How do I get the CDE software for my workstation?
  4.3    What do I get when I buy it?
  4.4    Is CDE safe/reliable/stable?
  4.5     Is an object-oriented GUI toolkit like Fresco in the works for
          CDE?
  4.6    How does the CDE relate to Motif 2.0?
  4.7    Can I license the CDE source code so that I can port it?

* Indicates new or significantly changed sections since the last
  revision.

1.5    What's not in the FAQ; what needs to be added?

1.5.1    Actual programming experiences and tidbits
Dos and don'ts of programming with CDE and other COSE (Spec 1170)
APIs.

1.5.2    Windowing Korn Shell (dtksh) example code
dtksh examples and fragments to be tried and reused.

1.5.3    Detailed questions about particular aspects of CDE and
the applications that come with the CDE.

2.0     COSE OVERVIEW

2.1    In general terms, what is COSE and why do we need it?

UNIX has long suffered from a lack of standardization across
platforms.  The lack of standard application programming interfaces
(APIs) force independent software vendors (ISVs) to spend up to fifty
percent of all development funds on maintenance of separate code and
testing for the many UNIX varieties.  Absence of standardization of
user interfaces causes significant user confusion and increased
training costs and requirements.  Finally, the lack of standard
administrative procedures leads to additional training costs as
administrators move between the various UNIX platforms.  All of these
factors have contributed to UNIX's reputation as a powerful, but
arcane operating system.  Over the years, a number of coalitions have
formed to attempt to unify the various UNIX interfaces into a single
broadly accepted, broadly available user environment.  The newest of
these coalitions is COSE.

COSE was formed by a group of companies on March 17, 1993.  The
companies that formed COSE are:

-    Hewlett-Packard Company
-    IBM, Corp.
-    The Santa Cruz Operation, Inc.
-    SunSoft, Inc (SUN Microsystems)
-    Univel (Novell)
-    UNIX Systems Laboratories, Inc (Now part of Novell)

Since the initial announcement, other vendors have agreed to support
COSE. From this point forward, the term "COSE" will be used to refer
to the collective membership of the group.

While the COSE vendors purport that COSE is merely a "process", that
COSE is simply acting as a "catalyst" to accelerate the standards, the
reality is that in all likelyhood, COSE represents the way that
standards for the future UNIX environment will be created. COSE is
developing reference implementations and draft standards in all areas
of open systems from kernel APIs to networking to desktop
look-and-feel.

Finally, it must be said that COSE was formed as the open systems
vendor's response to the coming of Microsoft Windows NT.  Windows NT
is the first non-UNIX based operating system to be available on a
number of systems architectures.  The scalability of NT makes
Microsoft's huge base in the Intel PC arena a threat across the entire
(performance) range of systems.  The availability of NT across
platforms finally delivers what UNIX and open systems have long
promised, a common API and look-and-feel across a broad performance
range.  It does so, however, at the expense of relying on a single
vendor, Microsoft.  The purpose of open systems is specifically to
avoid such vendor dependence.  Unfortunately, to this point, the open
systems processes have not managed to arrive at the required common
standards.  COSE represents the open systems vendors attempt to speed
development of such standards before Microsoft NT takes hold.

2.2    How does COSE work / What is the "new" OSF?

In March 1994, it was announced by the COSE vendors that many of the
developing reference implementations and draft standards would be
created by groups within OSF using OSF's new pre-structured technology
(PST) processes.  OSF's recently modified business model introduced
the PST concept, which is expected to compliment - not replace - the
traditional OSF Request for Technology (RFT) method for acquiring new
technology.  The PSTs are formed by paying sponsors that will use OSF
to oversee the project and monitor the prime contractor chosen by the
sponsors.  Each PST will be led by a Project Steering Committee, whose
members will often be employees of the sponsoring organizations.  The
development of a PST technology will be done by a prime contractor
chosen by the sponsors.  One or more of the sponsors may themselves be
subcontractors.  The creation of the PST process is intended to be an
improvement upon the RFT process used in the old OSF model.  There is
no guarantee that any, and certainly not all, COSE projects will be
accomplished through OSF RFT or PST processes.  Another important
event was the inclusion of former UNIX International companies, e.g.
Sun, among the sponsors of the new OSF.

The original CDE 1.0 work is still being done by the COSE vendors
outside of the OSF PST process, however.  The initial version of CDE,
CDE 1.0, is expected to be finished by the end of CY94.  In August
1994, IBM released AIX version 4.1.  CDE was delivered with that
release as the graphical user environment.  IBM was faced with either
continuing to supply IXI's X.desktop product, which IBM knew would be
made obselete in only a few months when CDE was released, or
delivering CDE in an "as is" state.  The CDE delivered by IBM was
incomplete and IBM added some temporary pieces to provide some
functionality.

An OSF PST for the follow-on to the first release of the CDE was
formed in March 1994.  The X Consortium is expected to be the prime
contractor.  The follow-on release has not been offically named, but I
will call it the CDE 2.0 PST for clarity.  In addition to the original
four vendors (HP, IBM, Novell, and Sun), DEC, Fujitsu, and Hatachi
have joined as sponsors of the CDE 2.0 PST.  For this PST, the
committee chairman is David Bealby from SunSoft.  I mention this only
because having someone from Sun chairing a committee within OSF would
have been unthinkable a year or two ago.  By the end of 1994, the PST
hopes to have completed the project definition and plan, submit the
plan to the OSF board for approval, and make the necessary commitment
of resources to the project.

The COSE vendors intend to submit a CDE 1.0 specification and sample
implementation to X/Open for standardization through the X/Open Fast
Track process. They hope that the specification will be adopted by
X/Open in early 1995. X/Open has announced a March 1995 target date
for the release of the CDE 1.0 specification. Internally, the COSE
developers use the following "triple-test" to determine if a
technology is suitable for becoming a COSE technology:

- Unencumbered specification defined - Specification is vendor neutral
and available to general public for reasonable licensing fees and
conditions - Sample specification/implementation available - Ongoing
management of specification by relevant vendor-neutral standards body

The general flow of the PST process begins with the OSF Architectural
Planning Council, which will publish and maintain a road map that
indicates the type of technologies that the OSF is interesting in
hosting.  All PST projects that the OSF Board of Directors approve
will be consistent with that road map.  Project Sponsors are
organizations (two or more) that are proposing an open systems
technology to be developed independently and monitored by OSF.  The
PST process could considered shared R&D.  If the project is accepted
by the OSF Board of Directors, the work will be performed by a prime
contractor designated by the Project Sponsors.  The prime contractor
or one of the subcontractors may even be one or more of the sponsors
themselves.  Once the project is established, the prime contractor
carries out the work to develop a reference implementation of the
technology.

Other technologies being considered for transition to PSTs include the
Distributed Management Environment (DME), OSF/1, Motif 2.0 (after its
August 94 release), and the Distributed Computing Environment (DCE).
Many of the other proposed COSE technologies such as System Management
or Objects may also be started as PST processes within OSF, but no
formal announcements have been made.

Once the reference technology has been completed to a logical
conclusion, the specification and any test suites will be submitted to
X/Open (or another standards body, when appropriate) for fast tracking
through the standards process.  The expectation is that the standards
organizations will agree to the COSE implementations and draft
standards with few changes.  Since the vendors play major roles in the
standards organizations, this is a reasonable expectation.  The
technology will be licensable to outside organizations directly from
OSF, and the sponsors are all inherently license for use of the
technology.  The sponsors will receive part of the proceeds from
licensing, but this is not expected to be the driving force behind the
inception of PSTs by the sponsors.  Once a standard is approved, the
vendors are committed to making a common behavior implementation
available on all their platforms.

OSF maintains that the PST process is being added to better meet the
realities of the marketplace today. The goal is to streamline the open
systems process and better facilitate collaborative development. In
this form, OSF transitions from technology developer to project
coordinator and a technology licensing body. The RFT process will
continue to be used in the areas of basic research and where there is
no consensus among vendors, but it is expected that the use of the PST
process will become prevalent.

2.3    How does COSE fit into the existing standards processes?

COSE is sensitive to the overall standards process.  Where a
promulgated standard meets requirements, COSE simply accepts the
standard and commits all COSE vendors to adhere to the standard.  In
those areas, COSE simply is guaranteeing even more openness than in
the past.  Customers will be able purchase any COSE "compliant" system
and be assured that the open, approved standard interfaces will be
available.  Where the process is moving forward, COSE has tended to
simply defer to the current process, and to state that COSE vendors
will provide the interfaces when the standard is completed.  In such
areas, non-controversial solutions will be available.  However, in
some areas, in the interest of moving standards forward at a more
rapid pace, COSE has defined APIs and interfaces that may not be
consistent with the direction of other standards bodies.

The decision of COSE to use X/Open instead of IEEE/ISO/ANSI/NIST for
establishment of formal COSE "standards" may be a problem.  The
problem stems from the following sources:

- X/Open is not an open process in the same way that the IEEE
standards are.  X/Open standards are agreed to by votes of the X/Open
directors and members.  Standards review and voting rights are given
*only* to paying members.  (When Novell agreed to turn over the UNIX
trademark to X/Open, Novell sought and received a post as a X/Open
director for a period of years.)  The cost to be a member of X/Open
varies depending on how one wants to be involved.  At a minimum, it
will cost $11K/year for a non-profit corporation to join the group
that formulates the requirements for the specifications (but not the
specifications themselves).  The cost can rise to over $500K/year is
an organization wants "broad brush" influence.  To join the Desktop+
working group that is working on CDE issues, the cost is $25K/year.

- X/Open "branding" is not free.  It costs money to go through the
X/Open test suite for branding as X/Open compliant.  These fees are
due yearly and based on the applicant's revenue.  The fees are a
minimum of $25K/year, which would be fairly steep for a start-up
company.  Initially, branding will be done against OSes for Spec 1170
compliance, but CDE compliance will likely follow soon with other
specifications for multimedia and objects following later.

A draft of the formal specification of the CDE, XCDE, was submitted
to X/Open for review and comment the first week of October. A final
draft will be submitted from the CDE vendors to X/Open before the
end of the year.  Another specfication called "Spec 1170" is also
in the works.  It is discussed in section 3.2.


3.0    DETAILS ABOUT COSE

The following paragraphs introduce the technology areas that were
originally identified by COSE. Several of these - most notably
multimedia, objects, and distributed computing - are apparently being
combined under the CDE umbrella. The first section is an overview of
all of the areas as originally proposed. The following sections are
more detailed information about those areas where details are known
with the exception of CDE, which is found in section 4.

3.1    What all does the COSE process encompass?

COSE is addressing all areas of computer systems from networking to
operating systems to user interfaces.  The next several paragraphs are
"one-liners" that describe those areas.  Those technologies where more
details are known are described in the following sections.

Common UNIX APIs - The Common APIs (Application Programming
Interfaces) are the operating system interfaces that will be called
"UNIX."  A common name for this specification is Spec 1170, which is a
reference to the number of APIs in the first draft of the
specification.  The interfaces include UNIX kernel APIs and commands.

Common Desktop Environment (CDE) - CDE includes look-and-feel, window
management, messaging services in the desktop, and commands and
programming APIs for windowing. It is based on Motif 1.2.3.

Graphics - Graphics standardizes line drawing, 3D graphics, etc.

Multimedia - Multimedia includes standards for integration of video,
audio, etc. with text.

System Management - System management includes standards for printer
interfaces, user and group management, software installation, etc. as
well as a framework.

Objects - Objects includes standards for handling of objects in a
heterogeneous, distributed environment.

Distributed Computing - Distributed computing includes standards for
underlying protocols, RPCs, and distribution of file systems.

Public Windows Interface(PWI) - PWI is an attempt to force the
Microsoft Windows messaging standards into the public domain.  The
sample implementation allows the execution of Windows software within
an X Window using a combination of 80x86 emulation and translation

Federated Naming - Federated Naming covers incompatible distributed
naming standards, principally Sun's Network Information System
(NIS/NIS+) and OSF's Cell Directory Service.(CDS).

Data Management - Data Management covers issues of large scale
hierarchical data storage and retrieval.

Representatives from COSE vendors have indicated that there might be
additional slices in the future.  One particular possibility was a
public Macintosh interface analogous to PWI.  Apple has recently begun
to market the Macintosh Application Environment (MAE), which runs
Macintosh applications on UNIX workstations within a Motif (CDE)
window, but with a Macintosh look and feel.

With the exception of PWI, COSE implementations for addressing
particular slices typically start from an existing open systems
standards base, but usually add to the base. The particular criteria
that COSE uses to decide how far to vary from the standards base
appears to depend on the particular slice of the COSE pie and the
maturity of the standards in particular areas. Where there are
competing, and potentially incompatible implementations, the tendency
seems to be to include all of the "standards."

Inclusion of multiple interfaces has several impacts. As part of the
COSE process, all COSE vendors have agreed to support all parts of
COSE on their systems. However, it was agreed that pricing and
packaging of particular bits of COSE would be up to the particular
systems vendors. This potentially presents both problems and
opportunities. For COSE to insist that SCO (Novell), for instance,
include a desktop on all copies of SCO would cause significant pricing
problems for them. Many SCO systems are used as point-of-sales systems
with ASCII terminals attached to a single standalone machine.
Requiring those systems to include and pay for X Window clients and a
server with their heavy RAM and disk requirements was regarded as a
real problem given the size of the SCO customer base using ASCII
terminals only. Price/performance comparisons of COSE systems,
however, will be complicated by differences in vendor packaging of the
various technologies. On the other hand, those complications will
allow users to only pay for those options that they require.

3.2    What are the Common UNIX APIs?

On September 1, 1993, many major hardware vendors and software vendors
said that they would support a draft COSE API specification to UNIX
called Spec 1170. The specification is called Spec 1170 because, at
the time of announcement, the specification contained approximately
1170 APIs. Spec 1170 covers APIs to kernels, C libraries, networking,
and command interfaces.

The COSE methodology for development of the specification is
representative of the overall COSE approach. COSE started from a
standards base, X/Open's POSIX-based XPG4. COSE then looked at the
systems calls used by the fifty most popular software packages for
calls that were "missing" from the XPG4 base. Based on that review,
COSE decided to add the SVID curses support, Berkeley sockets, and a
number of other APIs. COSE, however, did not necessarily include
everything they found in the software. If calls were rarely used or
vendor "enhancement" specific, COSE did not include the calls.

Note that the COSE software review was retrospective. If new
interfaces are emerging, they would not be found in the current base.
An example of this is the decision to not support a standard threads
implementation as part of Spec 1170. Threads give significant
performance boosts to applications on multiprocessor systems. However,
multiprocessor systems have only recently become widely available at
reasonable prices so few applications have been coded to support
threads in the past. The Institute of Electronical and Electronics
Engineers (IEEE) is currently working on a draft threads API in
POSIX.4a. Therefore, the API committee decided to defer decisions on
threads until IEEE finalizes its specification.

As announced during a June 22nd session at Xhibition '94, Spec 1170
has passed the draft stage and is in final editing within X/Open.  It
is not currently known what X/Open will call the specification.  The
current rumor is "Unified UNIX." The published specification was
expected in mid-September 1994.  However, I have not yet seen the
document, and I won't believe it 'til I see it.  The draft Spec 1170
documentation can be purchased on CD-ROM or electronically from X/Open
at this time.  In the US, you can telephone X/Open at [phone].
In the UK, X/Open can be reached at [phone].  (FAX: +44 (0)
734 500110.)

X/Open will develop test suites against the Spec 1170 standard. As
part of an agreement between X/Open and Novell announced in October
1993, the UNIX trademark was transferred to X/Open so that official
UNIX operating systems could be branded by X/Open against the
specification using a test suite to be developed. (The official
transfer of the UNIX trademark did not occur until around April or May
1994.) X/Open will brand systems as "UNIX" if and only if they pass
the Spec 1170 test suites. No vendor can legally call their system
"UNIX" unless they have passed the test suite and been branded.

3.3    What is going on in graphics?

This working group is defining the standards for 2D and 3D graphics
rendering under X. This is being done at the X Consortium level. The
defined standard is to adopt Xlib (for 2D drawing), PEXlib (for 3D
drawing), and XIElib (for working with images). These standards were
already the de facto standards in the industry. COSE intends to
support the standards bodies and hopes to accelerate the process.
Imagery exchange and file formats do not appear to be part of this
group's charter.

3.4     What is COSE doing about multimedia?

This working group is just forming. COSE plans to work through the
Interactive Multimedia Association (IMA) to define standards for
integrated video, audio, and text-based objects. In a meeting, HP
representatives also mention the Distributed Media Services (DMS) and
Desktop Integrated Media Environment (DIME) as subgroups.

3.5     What is COSE doing in regards to objects?

As part of the original announcement, all of the COSE members have
endorsed the Object Management Group's (OMG) process and committed to
shipping Common Object Request Broker Architecture (CORBA) compliant
products. As noted above, the question that must be asked is how does
the CDE interprocess communication scheme based on Sun's non-CORBA
compliant ToolTalk, fit into COSE's overall distributed computing
plans.

3.6     What is COSE doing in the area of distributed computing?

All six of the original companies have pledged to fully support
SunSoft's Open Network Computing (ONC/ONC+), OSF's Distributed
Computing Environment (DCE), and Novell Netware clients on each of
their systems. The transport layer supported will be TCP/IP protocols.
Of interest to government agencies, OSI protocols are not supported.
Note that, while all vendors agreed to support all three distributed
computing solutions, the three are incompatible with one another.
Users will be guaranteed that their preferred solution will be
available across platforms, but if users do not control all platforms
that they must internetwork with, there will be incompatibilities at
the interfaces between domains. The availability of all three also
means that ISVs that want to support COSE will need to maintain all
three interfaces in their software.

3.7     What is COSE doing about system management?

[This information is from the October 1993 CDE Developers Conference
where the working group was in the formative stage. I have no
up-to-date information on this group. Some of this is out of date. -
cap] As this part of UNIX has long been chaotic with every vendor
having different solutions in all areas, this group has a difficult
job before them. The overall intent of the System Management Working
Group is to develop core enabling technologies and APIs. Simple
solutions will be developed by COSE but more complex needs will be met
by ISVs developing against the standard APIs. The group has picked a
couple of areas in which they think that they can have an immediate
impact including:

- Software distribution and installation - Software distribution and
installation will be based on POSIX 1003.7.2. COSE intends to push for
completion of the standard and hopes to have a reference
implementation by the end of 1994. [This looks fairly unlikely
now.-cap] The resulting standard will support both push and pull
distribution. Policy distribution will come in later releases.

- Distributed Print Services - Print services will be based on POSIX
1003.7.1 June 93 draft, ISO 10175, and ANS.1. The software will offer
common APIs, GUI, and end-user desktop support. The tool is not
expected to be high end, but the APIs will allow ISVs to develop high
end applications. The working group expects to have a reference
implementation in 1994. [The print services work within CDE was
postponed until the second release. This also looks fairly unlikely
now.-cap]

Areas to be addressed later include:

- User and group management - The user and group management will be
based on POSIX 1003.7.3. This COSE subgroup is just forming [as of
October 1993].

- Software License Management - Software license management standards
will be available.  COSE has looked at a number of current licensing
schemes and has decided that none are sufficient.  COSE will develop a
standard approach.

- Backup and Restore and Data Management - The backup and restore
standard will be based on the current X/Open Backup Services API.  The
standard will also include hierarchical storage and retrieval
standards and APIs based on the Data Management Interface Group (DMIG)
and the IEEE Mass Storage Working Group Draft standards.  The System
Management group also is working with the recently formed COSE Data
Management group in this area.

Finally, the System Management Working Group plans to develop an
overall system management framework.  The framework is likely to
consist of APIs and services on CORBA.  The framework is expected in
1995.

3.8     What is the Public Windows Interface (PWI)/WABI?

COSE has committed to the development of a specification for a Public
Windows Interface (PWI). The specification is an attempt to move the
Microsoft Windows interfaces into the public domain. The Microsoft
Windows applications are more mature, have more features, and have
many more users than their UNIX-based counterparts. If COSE is
successful, one will be able to develop native 80x86 Microsoft Windows
code and run it on COSE compliant systems. The specification includes
Windows look and feel, messaging, and 80x86 emulation. A Windows
application running under a PWI implementation has the look and feel
of a Microsoft Windows application within an X window. The PWI
emulator intercepts Microsoft Windows graphics messages and translates
them into native X Window calls. The non-Microsoft Windows code is
executed either by software emulation (on a non-80x86 machine) or
execution in hardware (on a 80x86 machine).

3.8.1    Current release of WABI.

The SunSoft product WABI is a sample implementation of PWI.  Version
1.1 of WABI is currently available on SUN platforms and has been made
available to other COSE vendors.  This version offers an emulation of
Windows Version 3.1.  However, it does not offer support for DOS, DOS
networking, or Object Linking and Embedding (OLE2).  The current
product and the applications that run under it have a Microsoft
Windows look and feel.  Later versions of PWI will provide support for
networking.

3.8.2     WABI Performance.

SUN claims performance increases relative to native Microsoft Windows
applications. IBM has recently agreed to use WABI on its RS/6000 AIX
platforms. As part of its agreement, IBM will provide access to its
expertise in software emulation to attempt to increase performance.
Since PWI only runs the Windows front end natively and must software
emulate any calls to 80x86 processes, PWI performs much better on an
Intel-based hardware than on RISC-based hardware. If processes under
PWI are a significant portion of a user's job, Intel-based hardware
running UNIX may be preferable over RISC-based hardware.

3.8.3  PWI Look and Feel Issues.

The current version of PWI has a Microsoft Windows look and feel. A
user can launch Windows applications from within the base WABI
(Program Manager) window, or can launch a WABI compatible application
from a UNIX X Window desktop. In either case, the launched application
has a Windows look and feel. If the user is exclusively a PWI user,
the CDE login session can bring up a PWI interface that covers his
entire screen. The user gets standard Microsoft Windows drivability,
and the user session could be easily mistaken for a Microsoft Windows
session. On the other hand, if the user is only a part-time user of
PWI, the user sees applications with two different look-and-feel
approaches on the screen at the same time. On a Windows NT platform
that is not the case. Windows NT sessions have the same look-and-feel
as Windows 3.X sessions so 3.X sessions running under NT look and act
like NT sessions. The COSE vendors indicated that they had taken
Windows look and feel approach rather than a conversion to native
Motif look and feel approach so that users coming to UNIX from
DOS/Windows will not be faced with look and feel changes.

Related to the PWI look and feel issue, IXI has recently announced a
product, winTIF, that allows applications written to use the Motif
look and feel to display a Microsoft Windows look and feel instead. It
is intended for Microsoft Windows users that need to occasionally
access software developed to the Motif API from their Windows-based
desktops. This solves the look and feel issue for use of UNIX displays
to Microsoft Windows platforms.

3.8.4  Microsoft's Response to PWI.

As can be expected, Microsoft has responded to the development of
WABI/PWI.  Microsoft's response to PWI is three fold:

- Microsoft has indicated that the Windows interface is theirs.  Any
attempt to use it by others may be open to legal action.

- Microsoft control of the Windows "standard" allows for rapid
movement forward. The reason that UNIX has had such problems agreeing
is that UNIX vendors and the open systems processes often have
conflicting interests.

- Microsoft has signed an agreement with Insignia, makers of SoftPC,
to build a PWI-like product. Insignia's solution offers a Microsoft
Windows look and feel on UNIX RISC-based platforms. A Motif look and
feel is promised in a later release. The agreement gives Insignia
access to Microsoft Windows code for their development.

Insignia's access offers several advantages over a PWI solution:

- Insignia's solution will not be reverse engineered. Insignia's
access to the Microsoft code may yield better performance since it is
based on the Microsoft code. It may also yield better compatibility
when initially delivered.

- Insignia's solution will not tie Microsoft to a specific interface.
Microsoft will be able to modify their software and Insignia's
solution will easily follow along.  A reverse engineered solution like
PWI is likely to have time to market problems over time as the
"standard" Microsoft code is "enhanced".

- Insignia's solution does not face any legal challenges.

3.8.5  Potential Impact of PWI on Software ISVs.

PWI and the Microsoft-Insignia solution will have significant impacts
on software ISVs. The Microsoft Windows ISVs will now be able to sell
their products into the UNIX X Windows market without porting their
software to UNIX. The effects of PWI on the existing UNIX market will
manifest themselves in a number of ways depending on the type of
application:

- Applications that perform well under WABI are ones that are heavily
GUI intensive. Such applications typically are end-user productivity
applications.

- Common Windows applications will be available at Windows prices on UNIX
platforms.  Because of fierce competition and economies of scale, Windows
applications are typically much less expensive and have more features than
corresponding X Windows applications.

- Given that the size of the UNIX desktop market is about ten percent
of the Microsoft Windows market and that ISVs can now service that ten
percent by targeting the other ninety percent, it is questionable that
ISVs will undergo the expense of porting to UNIX workstations unless
there are significant performance gains to be had by doing so. The
gains are for the software that is heavily computational or server
oriented. For the most part, however, those ISVs are already ported to
UNIX and, in fact, many applications were initially developed on UNIX
and ported to the lower performance DOS/Windows platforms. Those ISVs
are now porting to the scalable Windows NT platforms and obtaining
similar performance to their UNIX native software.

- Users with interoperability requirements with Windows systems will
tend to move to the Windows applications for compatibility reasons.
Note that this specifically impacts organizations that use the
Microsoft Office product as their company standard since Microsoft has
not ported their products to UNIX.

3.9     What is COSE doing about Federated Naming?

[This information is from the October 1993 CDE Developers Conference.]
OSF's Cell Directory Service (CDS) and Sun's Network Information
Service (Plus) NIS+ are supported. DEC is sponsoring this effort.

3.10     What is COSE doing about Data Management?

[This information is from the October 1993 CDE Developers Conference.]
The COSE Data Management working group has recently been formed. They
are working with the Data Management Interchange Group (DMIG) on APIs
for hierarchical storage and retrieval. COSE also plans to make any
COSE data management solution consistent with the IEEE Mass Storage
Reference Model. Since that model is in draft form, COSE will work to
finalize the draft.

3.11    How will the COSE technologies be packaged?

As indicated above, some of the technology areas will be offerred as
options by some vendors. Persons acquiring a system on which they
intend to include COSE technologies will need to determine the
particular bits (technology areas) of COSE that their particular
system requires in order to be able to compare vendors prices. This
impacts using systems from different vendors in several ways:

- In the first place, there will be technical problems. Software that
assumes the presence of particular bits simply will not run without
them. On some systems, these will be included, and on others, they
will be an option.

- Secondly, there will be problems specifying and comparing prices
when purchasing systems. The purchaser will need to specify exactly
which pieces of COSE are required. Otherwise, there is no guarantee
that a particular vendor's bid includes all required parts.


4.0    DETAILS ABOUT THE COMMON DESKTOP ENVIRONMENT (CDE)

In the CDE, the vendors (not including SCO, who don't appear to be
involved in the CDE portion of COSE) are working closely together with
each contributing personnel and technologies to the effort of
producing a common user environment (desktop) that has reasonably
identical (considering that different vendors have different screen
resolutions, framebuffers, phosphors, etc.) look and feel across all
of the platforms.  COSE has taken what they feel is the best user
interface and desktop technologies from all of its vendors, and is
enhancing and combining them.  In the process of developing CDE, COSE:

- has solved the OpenLook versus Motif look-and-feel controversy;

- is developing a standard UNIX desktop;

- is standardizing on Sun's ToolTalk for interapplication messaging at
the desktop level;

- is creating a standard visual scripting language; and

- is opening up the desktop specification and programming APIs for
standardization through X/Open.

CDE will compete with and may replace current desktop managers such as
Visix's Looking Glass and IXI's X.desktop on UNIX workstations. IXI is
supplying tools to convert X.desktop's proprietary configuration files
and icons into COSE's CDE. The CDE is a coherent, visually elegant [in
the author's opinion], open user environment that takes full advantage
of the distributed multiprocessing UNIX environment. COSE expects to
deliver the CDE specification to X/Open and have vendor support for
the specification by the third quarter of 1994. X/Open plans to
publish the specification by the fourth quarter of 1994. CDE
implementations should be arriving from vendors beginning in early
1995 (if not sooner).

4.1    What is in the CDE?

The following paragraphs highlight the functionality of the CDE.

4.1.1    What is the CDE desktop?

Upon login, the user is presented with the CDE Desktop.  The desktop
includes a front panel, multiple virtual workspaces, and window
management.  CDE supports application launching from a File Manager,
from an Application Manager and from the Front Panel (also known as
the Dashboard).  Each of the subcomponents of the desktop are
described below.

4.1.2    What is the Front Panel?

The front panel contains a set of icons and popup menus (more like
roll-up menus) that appears at the bottom of the screen (by default).
HP's VUE product forms the basis for the CDE desktop.  The front panel
contains the most used applications and tools for managing the
workspace.  Users can drag-and-drop icons from the File Manager or
Application manager to the popups for addition.  The user can also
manipulate the default actions and icons for the popups.  The front
panel can be locked so that users can't change it.  A user can
configure 1-12 (or more) virtual workspaces each with different
backgrounds and colors.  Each workspace can have any number of
applications running in it.  An application can be set to appear in
one, more than one, or all workspaces simultaneously.

4.1.3    What is the File Manager?

CDE includes a standard File Manager. The functionality is similar to
that of the Microsoft Windows, Macintosh, or Sun OpenLook file
manager. Users can directly manipulate icons associated with UNIX
files, drag-and-drop them, and launch associated applications. The
associations are as described below under "File Action Binding /
Typing".

4.1.4    What is the Application Manager?

The user interaction with the Application Manager is exactly analogous
to File Manager except that is is intended to be a list of executable
modules available to a particular user. The user launches the
Application Manager from an icon in the Front Panel. Users are
notified when a new application is available on a server by additions
(or deletions) to the list of icons in Application Manager window.
Programs and icons can be installed and pushed out to other
workstations as an integral part of the installation process. The list
of workstations that new software is installed on is configurable.
The Application Manager comes preconfigured to include several
utilities and programs.

4.1.5    What is Application and File Action Binding/Typing?

CDE adds a veneer on top of the traditional UNIX file system by
allowing association of icons and actions to executable modules and
data files. The Action and Typing capability of CDE allows for a
file's type to be set by any combination of inspecting the contents of
the file and pattern matching on the name of the file. Once a file has
been "typed" an appropriate icon can be displayed for the file in the
front panel, application launcher, and file manager. Actions can be
assigned to icons so that associated commands are invoked when an icon
is clicked.

4.1.6    What is Session Management?

The session management portion of CDE is responsible for start up and
shut down of a user session. Also included is a login manager based on
XDM. In the CDE, applications that are made "CDE aware" are warned via
an X Event when the X session is closing down. The application
responds by returning a string that can be used by the session manager
at the user's next login to restart the application. Currently, CDE
"remembers" two sessions per user. One is the "current" session, where
a snapshot of the currently running applications is saved.  These
applications can automatically restarted at the user's next login. The
other is the default login, which is analogous to starting an X
session in X11R5/Motif and having X clients started up using entries
in the .xinitrc file. The user chooses which of the two sessions to
use at the next login.

4.1.7    How do I program with the CDE?

To a great extent, the CDE look-and-feel and programming APIs are
based on the Open Software Foundation's (OSF) Motif.  There are
extensions to the basic Motif APIs to cover new concepts such as
multiple virutal workspaces, ToolTalk messaging, and session
management.  As part of the initial COSE announcement, Sun agreed to
abandon OpenLook and support Motif.  However, the other COSE vendors
agreed that the COSE look-and-feel would be open, no longer controlled
by OSF.  In addition, while the look-and-feel is Motif-based, COSE
addressed Sun concerns regarding drivability and support for certain
OpenLook features and widgets that were not part of the Motif
specification.  Addition of those features eases Sun user and
developer transitions to COSE. The CDE environment is able to run
OpenLook applications without modification (on a Sun anyway). The
resulting CDE specification is a superset of the current OSF
Motif. COSE is working with OSF to merge the COSE additions into OSF
Motif.

COSE is also developing a look-and-feel style guide that vendors are
encouraged to follow. There will also be a branding/test suite
mechanism to ensure compliance. COSE hopes that marketplace
acceptance/pressure will also provide inducement for ISVs to seek
compliance.

4.1.8    How does CDE do drag-and-drop?

CDE's drag and drop is based on Motif 1.2.3. This will work with many
current and future X/Motif applications. This facility supports the
dragging and dropping of files even if they physically reside on other
workstations.

4.1.9    How does CDE support remote application execution?

CDE actions (See Actions and File Typing, above.) allow invocation of
remote applications across the network. Remote invocation is through a
CDE specific subprocess control daemon (dtspcd). The daemon overcomes
limitations of existing remote invocation mechanisms such as remote
shell (rsh) by passing the entire current user environment to the
remote process. The daemon also takes care of the xhost command
necessary to give the remote process authorization to display on the
local X server screen. Note, however, the daemon is new and is not
available on non-CDE platforms, even including the COSE vendor's
legacy systems.  Note also, COSE has not decided whether to publish
the interface definition to the daemon so that other vendor's
applications can use it.

4.1.10 How does CDE support inter-application communication?

Application messaging is currently based on Sun's ToolTalk. CDE has
built some convenience functions on top of the basic ToolTalk to ease
its use. It was strongly recommended at the CDE Developers Conference
that all vendors plan to incorporate ToolTalk interfaces into their
products. The problem to be resolved in this area is that ToolTalk is
not Common Object Request Broker Architecture (CORBA) compliant, while
COSE has indicated that object management services should be CORBA
based. It is likely that a software interface to CORBA services from
ToolTalk could be developed. Sun has indicated in the past that they
would provide such interfaces as part of Sun's Distributed Objects
Everywhere (DOE) project so such an interface is possible. Until such
an interface is available, developers may have to develop and maintain
interfaces to both CORBA and ToolTalk.

4.1.11 What utilities are included?

The CDE includes a number of standard utilities. The utilities
consist of:

- calculator - The calculator is a Motif version of the Sun
calculator.

- clock - The clock is analog only and embedded in the Front Panel.  A
digital clock is included in the desktop utilities and can be
installed in the Front Panel.

- the standard MIT X clients.

- A tool for file typing and icon action manipulation.

- Dialog and scripting services - Dialog and scripting services are
provided by the Desktop Korn Shell (dtksh). dtksh is similar to the
Korn Shell, but has quite a few structured programming extensions.
The COSE windowing extensions allow the shell to create, output to,
and read from Motif dialog and top level windows within a script.
Also, dtksh has the capability to interact with C code, which is
necessary for privileged code execution for security administration
such as adding and removing users. At this time, there is no support
for dtksh by any GUI builders, but a builder can be expected at some
time in the future. Once a builder is available, dtksh will become
the standard visual scripting language on UNIX. Projects requiring
"glue" code to tie together COTS products, for example, can be
developed in this language.

- A terminal emulator - The terminal emulator window application
supplied with CDE is dtterm, which is analogous to xterm. dtterm
supports full vt220 emulation and graphics. CDE extensions to MOTIF
provide developers the terminal emulator widget for inclusion into
their own programs.

4.1.12 What applications are included?

The CDE includes several desktop tools:

- A mailer. CDE's mailer has minimal support for multimedia. It
supports MIME format for attachments, and it will also be able to read
X.400 mail and Sun V3 (Sun's mailtool format) mail. (This will be
true when the tool is complete -- the reference version does not
provide the attachment features.) As with the desktop manager, the
mail sent by this tool will be interoperable with all supported
platforms. The mail tool also supports drag and drop of multimedia
via ToolTalk. Non-textual objects are represented as icons imbedded
in text and are accessed by clicking on the icons. Access launches an
appropriate tool for the object. Tool launching is handled using
ToolTalk.

- A multi-user calendar. The calendar tool is based on Sun's OpenLook
calendar tool, but has a new interface and added capability. The
calendar has a to-do list, an appointment/meeting scheduler, which can
be used to schedule personal or group appointments. The latter is
done by examining the calendars of the other members of the group
selected to participate in the meeting. An individual has several
ways to protect the information on their personal calendar. They can
make the calendar completely inaccessible to others, which defeats the
group scheduling capability. They can show appointment times as being
blocked out, but others in the group can not see the details of the
appointment. Or the appointment and details can be read by the group.
When a meeting is scheduled for a group, the person scheduling the
meeting can send mail to all the participants.

- A general purpose text editor/word processor. This is a lightweight
tool for text editing. It will probably serve best as an auxillary
application for use by the mailer and other applications. It supports
text wrapping with selectable margin settings, spell checking, search
and replace, X cut and paste, and file inclusion.

- An icon editor. This application is a fairly full featured
graphical icon (pixmap) editor. Actually, if it supported a few more
output formats like xwd or tif, this wouldn't be a bad (bitmap) paint
program. As it is, it is quite capable for creating icons. The
screen capture capability is particularly useful.

4.1.13 What is the CDE Print Server?

The print server (to be) included with CDE is essentially a
specialized X server. A few special functions were added to
initialize a print session, initialize a page, print a page, and end a
print job. The printed "page" is drawn using normal X/Motif commands
like XmDrawString. The size of the page and the resolution of the
page are attributes that the application drawing the page can
retrieve. Once the page is drawn, a command to print the page is
issued. The X print server calls a device specific driver to converts
the printed page to the language of the printer such as PostScript or
PCL (used by HP printers). Printer manufacturers need only supply a
driver to convert the printer server's representation of the printed
page to their printer's language. This is analogous to vendor's
supplying graphics buffer drivers for their specific displays in the X
server as is done today.

The basic print dialog is supplied by the CDE software, but individual
manufacturers are free to add to this dialog to allow for special
options for their printer. This is similar to what printer
manufacturers do for Microsoft Windows or the Macintosh today. In
addition to the print dialog there is the server dialog and the
printer dialog for selecting the server and printer, respectively, to
be used for a print job. This is analogous to choosing an AppleTalk
zone and printer with the Macintosh. The CD-ROM early release version
supports only black and white printing on PostScript and PCL (HP)
printers.

At Xhibition '94, it was announced that the Print Server will not be
in the official CDE 1.0 release (expected first half 1995). It is
expected that it will be in the CDE V2.0 release (probably 1996).

4.1.14 What is the Help System?

CDE provides an extensible hypertext based help system. A standard
GUI and widget is available and APIs are provided for loading the
system and using it from within applications. The help documents are
SGML-based and support both graphics and hypertext links in addition
to text. The CDE Look and Feel Guide strongly suggests that all
applications use the help system.

4.1.15 Any other features?

CDE includes a number of other features such as:

- APIs for internationalization;

- User preferences selection of colors, backdrops, fonts, and other
session parameters;

- ToolTalk enabled icon and text editors; and

- InterClient Communications Convention Manual (ICCCM) support.

4.2    How do I get the CDE software for my workstation?

If you wait long enough, the CDE software will come to a workstation
near you.  (IBM has released a early snapshot of the CDE with its AIX
4.1 release in August 1994.  See section 2.2 above for details.  Most
vendors are planning to release the first official version (1.0) of
CDE as their user environment in the spring of 1995.  If you would
like to start working with the CDE now, the second developer's
snapshot of the CDE is available through Uniforum.  At $150 (for first
time buyers - $25 for the 10/93 snapshot owners) this is quite a
bargain.  Shipping and handling not included.  Shipping was $5 in the
US.  Only HP, IBM, Novell (UnixWare), and Sun binaries are included at
this time.  The DEC port of CDE was demonstrated at Xhibiton '94.  It
was still a fairly early port with some rough edges, but they are
probably close to (pre-)releasing a developer kit.  TriTeal, Inc.  is
working on a port of CDE to SGI and other MIPS workstations as well as
porting the CDE to SunOS.  They also mention the AT&T MP RAS, DEC
OSF/1, and IBM AIX 3.2.5 (as opposed to AIX 4.1, which will include
CDE).  Tektronix and HP have also said that they will support CDE on
their X terminals.

HOW: Uniforum, under the sponsorship of the companies who developed the
   CDE code, will manage the order process. You will be able to
   order by mail, fax, or telephone. Send all orders and inquiries
   to:
     UniForum, 4/94 CDE Snapshot Order
     2901 Tasman Drive, Suite 205
     Santa Clara, CA 95054-1100
     USA

   Telephone (US and Canada)    1-800-986-1920 ext 30
   FAX (US and Canada)       1-800-986-1925

   Telephone (International)    1-408-986-8840 ext 30
   FAX (International)       1-408-986-1645

   (Business hours are from 8:00 AM to 5:00 PM Pacific Standard Time)

4.3    What do I get when I buy it?

A single CD-ROM disc contains the binaries for Sun, HP-UX, IBM AIX,
and Novell UnixWare platforms, as well as hundreds of pages of
documentation. The environment includes:

*** software / applications ***
 - dtwm, the "desktop window manager", which is essentially HP-VUE
  ported to the other platforms with some interesting other features
  added such as ToolTalk
 - a very usable file manager (with file typing and actions are nicely
  supported), which obviates you from purchasing one
  from IXI (X.desktop) or Visix (Looking Glass).
 - dtmail, an e-mail program that understands MIME and Sun V3
  (mailtool) formats (but still needs some bullet-proofing)
 - dtksh, a windowing Korn shell that allows scripts like:
    #!/opt/dt/bin/dtksh
    XtInitialize TOP hello Hello "$@"
    XtCreateManagedWidget H h label $TOP \
        labelString:"Hello World"
    XtRealizeWidget $TOP
    XtMainLoop
 - dtcm, a calendar/appointment manager that lets you keep your
  own to-do lists as well as schedule group appointments (with other
  people using dtcm). (based on Sun's calendar tool)
 - dtcalc, a calculator (based Sun's OpenWindow calculator)
 - dtbuilder, a GUI interface builder that handles the additional CDE
   widgets in addition to std. Motif 1.2.3 widgets and generates C code.
   Also, called "AppBuilder."
 - an extensive authoring facility for supporting online help
 - dtterm, terminal emulation widget, which supports VT200 emulation
   and can be added as a widget in your own software
 - dtpad, a simple notepad editor, which is not bad as simple editors
   go.
 - icon editor, support both xbm and xpm formats, lots of nifty icons
   supplied
 - Lots of GUI front-ends to UNIX tools like tar, df, etc.

The CD includes lots of development files like includes, examples,
etc.  The purpose of the CD-ROM is to provide an early development
environment to give ISVs a leg-up on developing for CDE. [IMHO, they
did a nice job.]

The /usr/dt directory contains:
app-defaults/ bin/      copyright   include/    palettes/
appconfig/   config/    dthelp/    lib/      scripts/
backdrops/   contrib/    examples/   man/

The /usr/dt/contrib directory has (ls -RC):
---------------------------------------------------------------------
dtaction/   dtdnddemo/  dtksh/    examples/
dtdatatypes/ dthelp/    dtwm/

./dtaction:
Makefile.HP   Makefile.SUN   dtactiondemo.c
Makefile.IBM  Makefile.USL

./dtdatatypes:
Makefile.HP  Makefile.IBM  Makefile.SUN  Makefile.USL  datatyping.c

./dtdnddemo:
Dtdnddemo   Makefile.IBM  Makefile.USL
Makefile.HP Makefile.SUN  dtdnddemo.c

./dthelp:
Help.h         Makefile.HP       helpdemo.app-defaults
HelpCache.c    Makefile.IBM      helpdemoHelpEnv.csh
HelpCacheI.h   Makefile.SUN      helpdemoHelpEnv.sh
Main.c         README
Main.h         help/

./dthelp/help:
Makefile    bike.bm    helpdemo.htg

./dtksh:
CallDataTest4*   ListBounds1*    SessionTest*    TransTest1*
CallbackTest2*   ListItemPos1*   TextCutBuf1*    WorkProcTest1*
DtCursorTest2*   ListPosSel1*    TextDisp1*      XdrawTest*
DtWsTest1*       PopupTest*      TextFXYPos1*    crMovesText1*
EventHandlerTest* SelBoxResTest*  TransEventTest*  ksh93.memo

./dtwm:
occupy/ wsinfo/

./dtwm/occupy:
Makefile.HP  Makefile.IBM  Makefile.SUN  Makefile.USL  occupy.c

./dtwm/wsinfo:
Makefile.HP  Makefile.IBM  Makefile.SUN  Makefile.USL  wsinfo.c

./examples:
sys.font.iso
------------------------------------------------------------------------
And lots of other stuff.

*** documentation ***
The documentation on the CD-ROM as PostScript files includes:
- Application Builders User's Guide
- (COSE CDE) Certification Checklist
- Internationalization Programmer's Guide
- Dtksh User's Guide
- Help System Author's and Programmer's Guide
- Programmer's Overview
- Programmer's Guide
- Advanced User's and System Administrator's Guide
- Getting Started Using ToolTalk Messaging

I was unable to print the CDE documentation without physically
attaching the (Apple LaserWriter IINT) printer directly to my
workstation and printing from the CD-ROM. For some reason when trying
to print across the network, the printing would stop as soon as the
first figure in the documentation was encountered. I have heard that
others had similar problems.

4.4    Is CDE safe/reliable/stable?

I have been using the CDE snapshot (on Sun LX, IPX, SPARC 10, and
SPARCserver1000) since it was handed out at the October 1993 CDE
Developers Conference. If all pre-release software were this stable,
I wouldn't need the "real" stuff. Except for the (very) occasional
glitch, CDE has been rock solid for me. I would like to hear how
stable it has been for others on other platforms.

I am now using the second (4/94) release, which added more
functionality such as the calendar and more functional mail. Some
parts are still under development. What is present, is stable. There
is a warning, however, in the documentation that the APIs are still in
flux and that changes may (will likely) occur before the official
release. This must be considered before starting any development with
CDE. There were several changes in the APIs and file locations/formats
from the first to the second snapshot.

4.5 Is an object-oriented GUI toolkit like Fresco in the works for
CDE?

I have not heard anything about Fresco by name, but OpenDoc, OpenStep,
and Taligent are on the minds of (i.e., being finacially supported by)
those who are the sponsors of COSE.  There has not been any public
mention of the plans for transition from CDE as it is today to an
object-oriented environment, but one is certainly needed since the
COSE sponsors are heading down that path.

The potential problem is that the new object-oriented environment from
Sun (i.e., OpenStep) does not interoperate with the environment from
IBM (i.e., Taligent) and that they have a different "look and feel."
This is precisely the problem that CDE is supposed to solve.  In a
session at Xhibition '94, Sun held a developer's meeting in which they
described the future desktop environment with CDE windows, OpenStep
windows, WABI windows, etc.  as a desirable thing.  Sun went further
to state that (and I am paraphrasing here) that developers could
choose between rapid application development (and all the other good
things from the object-oriented paradigm) using OpenStep or
cross-platform portability with CDE.  Of course, it might be nice to
have both.

4.6    How does the CDE relate to Motif 2.0?

At the OSF User Environment Component (UEC) Special Interest Group
(SIG) in May 1994, the status of Motif 2.0 and its relationship to
COSE/CDE was discussed.  As requested by the Motif SIG, Motif 2.0's
scheduled release date was postponed until August 1994 so that
enhancements and CDE compatibility work could be completed.  (Snapshot
3 of the Motif 2.0 Beta was released in May 1994.) After the release
of Motif 2.0, OSF will lay off its Motif development team and will not
develop any further releases under the RFT processes.  Starting a PST
process for Motif follow-ons is a possibility.  OSF expects that a
merger of CDE and Motif into a single PST will happen at some point in
the future.  The most likely time frame is early to mid 1996.  There
will be a method to license and fund the two separately.

CDE compatibility testing with Motif 2.0 reveals some
incompatibilities and mismatched features.  This is not surprising
since CDE is based on Motif 1.2.3 with enhancements rather than Motif
2.0.  The CDE enhancements are designed to increase Motif usability
and ease transition from OpenLook.  Some of the enhancements impact
the look.  Others impact the feel and drivability.  None of the CDE
enhancements change the Motif API, however, so Motif 1.2.3-4
applications should require only a recompilation to be CDE
applications.  The CDE includes as enhancements to Motif 1.2.3 several
items that were to be included in Motif 2.0.  For example, the
ComboBox and SpinBox, and Gauge widgets from CDE are also in the newer
Motif 2.0.  An enhanced FileSelectionBox widget (used when opening and
saving files) was added to Motif 2.0 from the CDE.  Some of the other
CDE enhancements can be implemented in Motif 2.0 by using and
enforcing pre-existing Motif options and properties.  Some CDE
components such as the terminal emulation widget and help widget have
no counterparts in Motif 2.0.

Depending on whether or not shared libraries are used, the CDE and
Motif environments can coexist to a varying degree. A dynamically
linked Motif 2.0 application can exist in the CDE environment if
particular attention is paid to proper installation of the
libraries. Problems occur with CDE applications if the Motif shared
library is allowed to replace the CDE shared library. If Motif 2.0
applications are statically linked, this problem is avoided and Motif
2.0 functionality is guaranteed in either the CDE or Motif
environments. If defaults are used for resources, statically linked
Motif 2.0 applications will exhibit most of the CDE behavior.
Applications developed against Motif 1.2 will work in the CDE
environments and have CDE behavior.

The Motif Style Guide has undergone some reorganization for
readability, convergence with IBM's Common User Access (CUA) and
Windows environments, and alignment with the CDE. CDE enhancements
incorporated into the style guide include additional mouse button and
menu pulldown capabilities. Allowing cascading menus outside of the
menu bar was also added for CDE consistency. Additionally, agreement
on the common look and feel for the new ComboBox, SpinBox, and Gauge
widgets was agreed upon. Finally, there were additions to the File,
Edit, and View menus and Help menu to agree with the CDE's use of
these features. The technical draft of the style guide is scheduled to
be delivered to X/Open in mid-August 1994.

4.7    Can I license the CDE source code so that I can port it?

As mentioned above, the CDE code is being ported to other platforms
than the original COSE vendor's hareware.  Eventually, the CDE source
code should be available from OSF like Motif is today, but the details
have not been finalized.  In the mean time, the source code can be
licensed from any of the COSE vendors directly.  However, the only
contact I have at the moment is Sandi Jones at Novell.  Her number is
408.577.6369.  I was not able to get a quote for the costs in time for
this cut of the FAQ.


------------------------------------------------------------
Craig A. Prall,            Telephone: [phone]
Member of the Technical Staff         Fax: [phone]
The MITRE Corporation         Internet: [e-mail]
7525 Colshire Dr. MS Z253
McLean, VA 22102-3481